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TRANSACTIONAL COMPUTER SYSTEM 



BACKGROXJND OF THE INVENTION 

This invention relates to a transactional computer 
system, namely a computer system adapted to perform 
5 negotiation and decision making functions related to a 

transaction . 

Transactional computer systems are known for use in 
the financial and business world for conducting 
- transactions such as, for example, ordering product,' 
10 currency exchange, or the sale and purchase of, stock, 

shares and bonds. Such systems are designed specifically 
for the particular function or functions which they are to 
perform. 

Rule-based systems using what is generally known as 
15 artificial intelligence are also known. These are based 
on a large number of rules which are specific to the 
particular environment in which they are to be used. A 
given system is designed for a particular type of 
transaction, and if a new type of transaction is envisaged 
20 a new system will have to be' designed specifically for 

that purpose. 

We have appreciated that it would be highly desirable 
to provide a generalised transactional system which can be 
adapted to many specific types of transaction, and 
25 furthermore we have appreciated that such a generalised 

transactional computer system can be made by using the 
ideas and features described in the following and claimed 
in the claims appended to this description. 



SUMMARY OF THE INVENTION 

The invention is defined in the independent claims 
below to which reference should now be made. Advantageous 
features are set forth in the appendant claims. 

According to the present invention there is provided 
a transactional computer system comprising a plurality of 
entities j.ncluding at least one entity of each of the 
following forms, a first entity (Thing entity) having the 
properties of identifying a client system and uniquely 
identifying an object in that client system, a second 
entity (Proposal entity) for defining a transaction, the 
second entity being subordinate directly or indirectly to 
a first entity and having the properties of modelling at 
least one external agent to carry out a transformation in 
relation to the first entity, and a third entity (Decision 
entity) capable of communicating with a second entity and 
having the properties of defining the types of decision 
that may be made, and determining the responses in 
relation to those decisions. 

Preferably the computer system further comprises at 
least one fourth entity (Assignment entity) subordinate to 
an associated first entity, the fourth entity having the 
properties of uniquely identifying the associated first 
entity, and identifying a particular type of assignment or 
transformation to be applied to the first entity. This 
entity may be combined with the second entity. 

Additionally the computer system preferably further 
comprises at least one further entity (Tender entity) 
associated with a plurality of second entities and a 
single first entity, and identifying at least a quantity. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will now be described in more derail by 
way of example, with reference to the drawings, in which: 

Figure 1 illustrates the heirarchical structure of 
the entities in a preferred computer system embodying the 
invention; 

Figure 2 is a flow chart illustrating the MewEntity 
procedure in the preferred embodiment of the invention; 

Figure 3 is a flow chart illustrating the 
RegisterEntity procedure in the preferred embodiment of 
the invention; 

Figure 4 is a flow chart illustrating the 
LoadHierarchy procedure in the preferred embodiment of the 
invention; 

Figure 5 is a flow chart illustrating the Math: 
AddDecision procedure in the -preferred- embodiment of the 
invention; 

Figure 6 is a flow chart illustrating the Cube: Apply 
Decision procedure in the preferred embodiment of the 
invention; 

Figure .7 is a flow chart illustrating the 
Item (EntityKey) procedure in the preferred embodiment of 
the invention; 

Figure 8 is a flow chart illustrating the Math: 
GetMathValue procedure in the preferred embodiment of the 
invention; and 

Figure 9 is a flow chart illustrating the Cube: 
GetValue procedure in the preferred embodiment of the 
invention . 




- 4 - 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

GENERAL DESCRIPTION 
This system is embodied in a computer software module 
which, when included in a client system, will capture the 
5 complexity of its negotiations, but leave the description 

of those transactions to the client system. The system 
makes possible the management of the transaction space in 
a straightforward and effective manner. It does not, 
however, manage the transaction space directly. Rather, 
10 it supports the modelling of the transaction space in a 

convenient and effective manner, and then, once modelled, 
it is for the client system to respond to the situations 
discerned and captured in the model. The power of the 
system is in its flexibility for modelling and managing 
15 the client system* s complex transaction space. 

The system will only capture and supply information 
without using it for its own internal manipulation. It is 
better to record what people claim, and then leave the 
external clients/parties to resolve their claims, than it 
20 is to try to decide the truth of a matter. Consequently, 

the validity or otherwise of the supplied information has 
no bearing on the system. However, it may have a 
significant bearing on the satisfactory use of the system; 
therefore the client system should validate the 
25 information supplied and act accordingly. 

The system comprises a hierarchy of entities: a 
Thing, a Proposal and a Decision, and optionally an 
Assignment and/or a Tender. Each entity type has a set of 
properties appropriate to its role. These are described 
30 in more detail below as part of the preferred embodiment. 

It is a feature of the system that an extension of the 
modelling environment can be achieved by the provision of 
additional properties per entity. 



THE THING ENTITY 
The system supports the modelling of the existence of 
external objects by provision of a 'Thing' entity. In the 
preferred embodiment, the Thing entity has fields 
ClientSys tern, and ClientSystemRef erence . The ClientSystem 
field is- an identifier of the client system itself, and 
the ClientSystemRef erence field is an identifier by which 
the implicit existence of an object identified by that 
Reference is posited. 

No validation as to the nature of that implicit 
object is either attempted or warranted, nor of any other 
information pertaining to the world outside the system. 

A ClientSystemRef erence to a Thing must be unique, so 
that all behaviours and data to a common external thing 
will be mapped and managed by a common internal Thing. 
Client applications must ensure that they have implemented 
an appropriate . nomenclature to ensure unique references 
per client system. 

THE ASSIGNMENT ENTITY 
Tp_e system supports the modelling of assignments or 
transf oriaations applied to external objects. It does so 
by provision of an 'Assignment' entity. An Assignment, 
for the purposes of the system, is regarded as a 
transformation that may be applied to a Thing, for example 
an operation which can be conducted in relation to an 
object. Thus, in the system's entity hierarchy, an 
Assignment is subordinate to and applies to a Thing. 

An Assignment will comprise in particular an 
identifier for the particular type of assignment or 
transformation to be applied. This key information is 
supplied by the external client system in. the Assignment's 
'Redirection' field, see below. 
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LINKING ASSIGNMENTS 
The system supports sequential modelling of - 
assignments. As an example: with a Thing (CAR), 
Assignment (WASH) might be followed by Assignment ( DRY) . 
The assignment sequence is maintained by referring to WASH 
as the predecessor to DRY. 

THE TENDER ENTITY 
The client system is allowed to group together a set 
of proposals, thus allowing more complex negotiation 
behaviours to be modelled. For example, as its name 
implies. Tenders and auctions may be modelled. The system 
allows the creation of the Tender entity and notes its 
corresponding external reference. 

THE PROPOSAL ENTITY 
The system includes an important facility to model 
the existence of agents to carry out the transformations. 
As an example this might be a cleaning machine which is 
required to wash a car. This is supplied by a 'Proposal* 
entity . 

A client system wishing to identify the potential for 
an agent to impact an assignment's fulfilment will create 
a Proposal. Since in the preferred embodiment the 
Proposal has a bearing on a particular Assignment, it is 
subordinate to an Assignment in the hierarchy and in the 
preferred embodiment applies to a single Assignment only. 
Where there is no Assignment entity, a Proposal may be 
subordinate to a Thing; either way it is seen that a 
Proposal is subordinate directly or indirectly to a Thing. 

The identification of an agent by a client system is 
at no time validated by the system, but i^ deemed to be 
supplied by the client system as a rational and 
satisfactory identity . 

The system provides for modelling situations where 
the potential action of the agent may often have arisen as 
a matter of negotiation. The counter-party to the agent 
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in this negotiation is also identifiable by the client 
system. 

The system includes a facility to distinguish the 
current direction of the negotiation . 

The Proposal itself carries a rich set of features, 
sufficient and appropriate to the complexity of the 
environments it is intended to be capable of modelling. 

The preferred embodiment supports the following 
features within a Proposal, each being a field supporting 
input by the client system. The identity of the agent 
capable of impacting the Assignment is held in the field 
'Downline'. The counterparty to the agent in this 
negotiation is held in the field 'Upline'. In regard to a 
specific proposal, the Upline will have no direct impact 
upon the Assignment. The direction of the negotiation is 
implemented as a boolean flag ' DirectionGoingUp ' , which 
may be either true or false. 

For example, a proposal going DOWN, whereby the party 
making the proposal is the Upline and expects a reply from 
the Downline, models a request or command. Conversely, a 
proposal going UP, whereby the party making the proposal 
is the Downline and expects a reply from the Upline, 
models the function of volunteering . 

A proposal is something to be considered and a 
decision made on it. A proposal is therefore conveniently 
recorded using the expression Consider, Do, as will be seen 
below . 

GROUPING PROPOSALS 
By grouping proposals it is possible to extend rhe 
flexibility of the modelling environment to support the 
tracking of complex interactions. For example, cause and 
effect, flow modelling, command and control and the like, 
can be grouped. This grouping is accomplished by using 
Subordinate Proposals and Sibling Proposals. 
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SUBORDINATE PROPOSALS 
A further feature of the preferred system is the 
modelling of subordinate proposals. For example, in a 
factory, a Thing (CLIENTORDER) with an Assignment ( FILL) lua^ 
5 require -sequence of proposals before it can be 

fulfilled. This may include the interaction of several 
people. These proposals should be grouped together. To 
achieve this the ProposallD of the Superior proposal is 
recorded in all subordinate proposals using the field 
10 Super iorProposalRef ID . 

SIBLING PROPOSALS 
A further feature of the system is the grouping 
together of proposals regarding the same matter. For 
example, if in a warehouse a customer wants 1000 ball 

15 bearings, but there is only 800 on the shelf, then 200 

will have to be refused. All of this information will be 
stored in many proposals, but all regarding the same 
matter :'i.e. the order for 1000 ball bearings). To 
achieve this grouping all sibling proposal entities store 

>0 the original ProposallD in the field SiblingProposalRef ID . 

COMBINED PROPOSAL/ASSIGNMENT ENTITY 
As described above, the assignment entity is 
optional. The features of the assignment entity, if 
included, may be combined with a proposal entity to 
5 provide a combined proposal/assignment entity which has 

the properties of both a proposal entity and an assignment 
entity. 

THE DECISION ENTITY 
0 The system records the response from the 

counter-party in regard to a corresponding proposal. This 
is the role of the Decision Entity which is subordinate to 
and can communicate with a single one of the Proposals. 
Delegated proposals are tracked by passing the Decision 
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for a Subordinate Proposal to the Superior Proposal. An 
individual 'position in a negotiation is tracked by passing 
a Decision for a Sibling Proposal to all the other Sibling 
Proposals with the same SiblingProposalRef I D field. 
5 The response recorded by the decision entity can be: 

decline, accept, partially accept, or forward. Forwarding 
involves accepting the proposal but finding another agent 
actually to undertake it. The responses are recorded in 
the form Decline. Do, or Accept. Do, and so on, as 
10 appropriate. 



THE DECISION SCHEMA 
In order to derive effective meaning from the system, 
external decisions need to be recorded in a consistent, 
effective and intuitive manner. The protocol for so doing 
is implicitly provided by the creation of a logical 
structure, termed the decision schema. The decision 
schema comprises multiple dimensions and defines what 
types of decision may be stored. Each dimension comprises 
a set of direct fields and a set of derived fields: 

Direct fields define the types of decision that may 
be stored. 

Derived fields summarise the consequences or impact 

of the decision. 
It is desirable that the direct fields represent a 
set of mutually exclusive states, whereas the derived 
fields need not be mutually exclusive. Each field is 
assigned an index into the dimension. A decision type 
node is then defined as a vector, comprising one index 
from each dimension. Decisions of that type have their 
quantities applied to that node, so that each node 
accumulates a summary of like decisions. • 

The Decision Schema is a facility which client 
applications may use to model complex negotiations in a 
manageable and effective manner. A client application 
must, however, be clear as to its decision semantics, in 
order to make use this feature. An example of a Decision 



Schema is given below in the more detailed description of 
the preferred embodiment, 

THE DECISION CUBE 
A decision cube is built in the code in the form of 
multidimensional array. It is used to store the 
quantities associated with each decision. Each element o 
the array should be initialised to zero. 

DESIGN PRINCIPLES FOR DECISION SCHEMAS 
Decision states (within a dimension) are exclusive. 
It is meaningless to record both an agreement to NotDo 
something, and yet that it is Done. If an agent agrees t 
NotDo something, and yet declares it Done, then it is 
regarded in the context of the system as a rogue agent. 

The decision cube does not oreclndf=^ recording 
inappropriate or meaningless information. As noted above 
it is a fundamental design principle that it is better to 
record what people claim, and then leave the external 
clients (or parties) to resolve their claims, than it is 
to try to decide the truth of a matter. Thus the system 
can record both a NotDo and a Done, and let the client 
system scan for such occurrences, and then implement 
whatever procedures necessary at that point. 

Decision states may be partial. This requires the 
proposal to have a Quantity. For example: a proposal to 
ship 12 crates of water (Consider . Do . 12 ) may have the 
response; Accept. Do. 6, Decline . Do . 4 ; leaving 2 undecided 
(Pending) . 

This also leads to a further observation: that a 
proposal using a Quantity is deemed to refer to a 
homogeneous assignment. Thus, with shipping bottles of 
water, it is assumed that the parties to the proposal are 
indifferent between two bottles of water from the same 
assignment. If partial quantities need to be 
differentiated, then they should be differentiated as 
different Things, and then renegotiated accordingly. 
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Thus a crate of 20 pieces of fruit (12 Apples and 8 
Oranges) is perfectly acceptable as a Thing, provided the 
system is not expected to discriminate between Apples and 
Oranges. If it is, then it should be registered as 2 
5 shipments: one of Apples [Quantity 12], and the second as 

Oranges [Quantity: 8] 

OPTIONAL ENTITIES 
The entities Assignment and Tender are optional 
members of the hierarchy. Specifically a Proposal may be 
10 created for a Thing without requiring an Assignment or 

Tender. This facility is provided to support very simple 
scenarios, without the overhead of the unnecessary 
creation of Assignment and Tender entities. The hierarchy 
will always include Thing, Proposal and Decision entities. 
15 This heirarchical structure is illustrated in Figure 1. 

REQUIREMENTS 

The basic requirements needed to support a physical 
implementation of the system are: 

A facility to define the distinct Entities, their 
20 Properties, and the Values associated with 

these Properties. 
A facility to create the Entities 
A facility to have such Entities persist. 
A facility to identify particular instances of 
25 Entities. 

A facility to set, edit and retrieve the Property 

Values of such Entities. 
A facility to manipulate Entities in a Hierarchy. 
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THE PREFERRED EMBODIMENT 
The processes required to implement the system' will 
now be described in more detail, including in particular 
the construction of the Entity hierarchy, and adding 
decisicr*.^ to the hierarchy. 

The specific functions (processes) described in more 
detail below are: 



NewEntity ( ) 



RegisterEntity ( ) 



LoadHierarchy ( ) 



ApplyDecision ( ) 



Item( ) 



Cube: GotValue ( ) 



Notif yEvent ( ) 



The facility to create a new member 

entity of the hierarchy 

The facility to load an entity (into 

memory) 

The facility to load directly a full 
subordinate tree 
The facility to increment the 
multidimensional data array, or cube 
The facility to retrieve a pointer 
to a member entity 

The facility to retrieve a cube's 
value at a particular node 
Advising Client System of an event 



Of these functions, only two are intended to be 
accessible to clients/parties external to the system, 
namely NewEntityO and Item(). The function 
LoadHierarchy () could be achieved by multiple applications 
of RegisterEntity ( ) but it is convenient to have it 
available as a separate function in its own right. 

The only further facility required to provide an 
effective minimal embodiment of the system is then: 



EntityPropertyValue () : Retrieve the Value of a 

Property of an Entity. 
This is a trivial process and need not be further 
discussed . 



- 13 - 

The utility of the system will often require a client 
application to be able to determine the stare of a 
particular entity, by examining its properties. This 
function provides that facility. 
5 The following describes the sequencing and 

sub-processes necessary to support each of uhe key 
function processes highlighted above. The descriptions 
should be read in conjunction with the flowcharts in 
Figures 2 to 9 with the same title. Numeric references 
10 refer to these flow-charts individually. 

In the preferred embodiment of the system, the 
hierarchy consists of Things, Assignments, Tenders, 
Proposals and Decisions. Since their processing internal 
to the system is largely similar, so it is more convenient 
15 to regard them all as instances of a generalised Entity. 

An implementation of NewEntity() therefore may be read as 
"Construct a facility, of the type: 

NewEntity (EntityTypeName) where EntityTypeName is one 
of: Thing, Assignment, Tender, Proposal, Decision." 
20 This allows further hierarchies to be readily developed, 

but at the cost of more sophisticated code to handle the 

distinct types. 



25 



Notation : 

Numbers: 1. 
Restrictions: [Thing only] 



30 



Exclusions 



Universal : 



[Not Thing] 



[All] 



Numbered boxes in the 
accompanying flow-charts , 
Entities only of [this] 
type 

Entities nou of [this] 
type 

Entities of all Types. 
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NewEntity () 

This is the facility to create a new member entity of 
the hierarchy and is illustrated in Figure 2 of the 
drawings. The procedure applies to all the entities 
5 Thing, Assignment, Tender, Proposal, and Decision. Note 

however that Step 1 applies only to a Thing, Step 4 does 
not apply to Decision, and Step 5 applies only to 
Decision . 

Arguments: The properties of that Entity. See Entity 

10 Properties, below. 

1. [Thing only] A Client Reference to a Thing should be 

unique. A check is made to see if such a Client 

Reference already exists, 
la. If it does, the process is deemed to have failed. 
15 2. [All] Add a new record to the appropriate EntityType 

database table. Include the data from the arguments 

to the NewEntity(.) call, 
3, Retrieve a unique ID (within that EntityType) for the 

new entity. 

20 ^- Register () the new entity in memory, see below and 

Figure 3. (Create a new object in memory, of that 
type, with the appropriate data as supplied by the 
arguments in the call to the function.) 

5. Proposal: Math: AddDecision ( ) , see below and Figure 
25 5. Since something has happened which could have a 

bearing on the client systems behaviour (e.g. a new 
Thing to be considered, new Assignment to be 
processed, new Tender to be negotiated. Proposal to 
be considered, or Decision to be evaluated) , so an 
^0 EventNotif ication is sent out to the client system to 

make it aware of the event, in particular its type, 
and its ID. See Notif yEvent ( ) 

6. Notif yEvent 0 . Finally, an ID is returned (non-zero, 
in this embodiment)-, unique within .the EntityType, so 

^5 that the caller of the process may subsequently refer 

to this particular new entity, in calls to Item(), by 
its new EntityName . 
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Regis terEntity () 

This is the facility to load an entity (into memory) , 
and is illustrated in Figure 3 of the drawings. The 
procedure also applies to all the entities Thing, 
5 Assignment, Tender, Proposal, and Decision. Note however 

that Steps 2, 3, 4 and 6 do not apply to a Thing, Step 
does not apply to Assignment, Step 7 does not apply to 
Decision, and Step 9 applies only to Thing. 

Arguments: The properties of that Entity. See Entity 

10 Properties. 

Arguments: In addition, the ZD's of the Entity's 

superiors in the Hierarchy. 

1. A check is made, to discover whether this particular 
entity has already been loaded. If so, there is no 

15 need to load it again. Processing proceeds to Step 

11, where a Pointer to the Entity is returned, so 
that the calling function may directly reference its 
properties. 

2. [Not Thing] Item(): Get pointer to superior thing, 
20 see below and Figure 7. As the Entit^Type 'Thing', 

is the root of the Hierarchy structure, all instances 
of subordinate EntityTypes (but not a Thing itself, 
hence -the exclusion) will have a superior Thing. 
This step proceeds to get a reference to the entity's 
25 superior Thing, by a call to Item (ThingID) , The 

ThingID is passed, along with the ID's of any other 
superior entities, in the call to the function. As a 
further consequence of the call, since Item() will 
load the Thing if not already loaded, it will load 
the full hierarchy particular to this Thing, 
including the entity which is being attempted to be 
registered. Hence this call is recursive if the 
Thing was not already loaded. Thereafter, the Thing 
being loaded, there is no further call to load the 
35 hierarchy, and hence to register the entity which 

originated the call to Thing. In the recursive case, 
this process again checks to see whether or not the 
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subject of the original call has now in the interim 
been loaded. 

[Not Thing, Not Assignment] This step calls ItemO as 
required to get pointers to further superior 
entities. A Thing has none, and as Assignment has 
only.- a superior Thing, so both are excluded from this 
seep. These pointers will be used in Step 6, to 
allow an entity to directly reference its superiors. 
This step also provides an opportunity to ensure that 
the superiors specified in the call to this function 
are all available, and appropriate to the entity 
being registered, 

[Not Thing] See Step 2. Due to the recursive nature 
of the call to Item (ThinglD) , this step checks to see 
whether the originally requested entity has now in 
the interim been loaded in memory. 

[All] In this step, a . blanJ< (uninitialised, data 
unspecified) instance of this class of entity is 
created in memory. 

[Not Thing] All objects other th an a Thing will have 
superiors. In this step, the pointers gathered in 
ST-^rps 2 and 3 are now assigned to appropriate 
properties in the new memory instance. In this 
particular embodiment, only the immediate superior in 
the hierarchy is assigned to the new memory entity. 
Higher superiors may then be accessed by chaining 
entity properties, e.g.: 

(Visual Basic) Proposal . Tender . Assignment 
(C++) Proposal ( ) ->Tender ( ) ->Assignment ( ) . 

[All] Create and link a Math Crystal. This step 
assigns the property values, passed as function 
arguments, to the appropriate Ob j ect . Properties . 
Hereafter, a client system or internal routine will 
be able to directly determine the state of the 
object, by accessing these Property Values. 
Assign the Entity's data. 
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[Proposal Only] A Proposal has a Property Quantity c 
more exactly Consider Quantity. This is the amount 
that is being offered for consideration. Where the 
field is not used or required, it may be deemed to 
have a value 1. It is therefore meaningless to 
consider the impact of decisions (how much has been 
agreed, etc.) if the original target is not known. 
This step therefore adds a Decision as a "Consider", 
with Decision parameters Action and BidWanted derive 
from the proposal properties. 

[Thing Only] LoadHierarchy ( ) , see below and Figure 3 
As described earlier and elsewhere, loading a Thing 
also loads the entire hierarchy subordinate to a 
Thing. It is achieved by a call to the 
LoadHierarchy ( ) function . 
11. [All] Processing complete, the process will return a 
Pointer to the newly created memory object. 

LoadHierarchy ( ) 

This is the facility to load directly a full 
subordinate tree, and is illustrated in Figure 4. Note 
that Section I comprising Steps 1 to 5 processes the 
intermediate entity types Assignment, Tender and Proposal. 
Section II comprising Steps 6 to 9 processes the entity 
type Decision. 

Arguments: The ID (ThingID) of the Thing whose 

hierarchy is to loaded. 
The process needs to load all the Assignments, Tenders and 
Proposals associated with a Thing. it does this by 
Registering the Entities. The procedure is described 
therefore as follows. 
Section I . 

1. [Not Thing, Not Decision] The process initiates a 

sub-process for each intermediate EntityType in turn. 
The hierarchy subordinate to a Thing is being loaded, 
so Thing is redundant and excluded. Decisions are 
treated differently, later, and so here excluded. 
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2. Each EntityType's stored data (database table, in 
this embodiment) is searched for instances of this 
EntityType, with the particular Thing as their 
superior (ie: having matching ThingID) . For each 

5 found instance, another sub-process is initiated, 

which comprises Steps 3 and 4. 

3. For each entity instance matching the Thing, the 
entity's particular data is retrieved. 

4 . The new data is passed as arguments in a 
10 RegisterEntity ( ) call, to load the found entity into 

memory. Control then passes back to Step 2, to 
search for the next matching instance, 

5. Once each entity type has been fully searched, 
control passes back to Step 1. If ail intermediate 

15 types are complete, it passes on to Step 6. 

Section II, 

6. With the intermediate types complete, the processing 
of Decisions is now initiated. A loop is initiated, 
wherein the Decisions table is searchtrd for decisions 

20 subordinate to the required Thing (matching 

'ThingID*). For each matching decision, a 
sub-process is initiated, comprising steps 7, 8 
and 9 . 

7. For a matching decision, the data is retrieved from 
25 the table. 

8. From the Decision's ProposalRef ID Property, and 
following a call to Item(), a pointer to the 
Decision's Superior Proposal is retrieved. 

9. Proposal: Math: AddDecision ( ) is executed, see below 
30 and Figure 5. 

10. Once all decisions matching the Thing have been 
processed, the process is complete. • 
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Math; AddDecision 

This function is called in NewEntity and 
LoadHierarchy above, and is illustrated in Figure 5 of the 
drawings . 
Argument : None . 

1. A determination is made as to whether the decision 
source is subordinate. If it is, control passes to 
Step 2. If it is not, control passes to Step 3. 

2. The procedure sets Cube=Derived Cube. 

3. The procedure sets Cube=Normal Cube. 

4. Cube : ApplyDecision ( ) , see below and Figure 6. This 
determines the quality and type for the selected 
cube , 

5. A determination is made as to whether the Decision 
Source is Normal (see Steps 1 to 3) . If it is, 
control passes to Step 6, If it is not, control 
passes to Step 7. 

6. Math: Add Decision- to Hierarchically Superior Entity. 

7. A determination is made as to whether the Proposal 
has a Sibling Ref. If it does, control passes to 
St.^p.B. If it does not, control passes to Step 9. 

8. Math: Add Decision (Sibling) to Sibling Proposal. 

9. A determination is made as to whether the Proposal is 
derived from another Proposal. If it is, control 
passes to Step 10. If it is not, control passes 

to Step 11. 

10. Math: Add Decision (Derived) to DerivedFrom Proposal. 

11. Processing complete. 



Ciobe : ApplyDecision ( ) 

This is the facility to increment the Decision cube * s 
data which is called in Math: AddDecision above, and is 
illustrated in Figure 6. 

Arguments: Decision parameters. Decision Quantity. 

1. This process needs to translate the decision 

parameters into a node location. It therefore 
iterates through each of the decision parameters. 
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2. Selecting the Decision Dimension Key for each 
parameter in turn. 

3. It translates the key into an index into that 
dimension of the cube. (See Decision Cube.) 

4. The set of key indices thus obtained then form a 
vector into the cube, so selecting a particular node 
in the array. 

5. The node at this key is then incremented by the noted 
quantity. 

6. The derived fields in the decision schema are then 
recalculated. 

7. The process is then complete. 

ItemO 

This function is called in RegisterEntity above, and 
is the facility to retrieve a pointer to a member entity, 
and is illustrated in Figure 7. 
Arguments: Entity Key 

1. From the Entity Key supplied, the collection of 
similar EntityTypes in memory is searched, to 
discover whether or not the Entity is already in 
memory. If it is, the process moves to Step 4, and 
returns a pointer to the entity. 

2. If the entity is not in memory, the process calls the 
ItemO function with the Entity's ThingID to get a 
pointer to the superior Thing. 

3. Since a call to Item (ThingID) always loads the full 
hierarchy, subsequent new entities will also be 
directly loaded into memory. Step 3 is not a 
process, but simply acknowledges that Thing, and its 
full hierarchy, including the required Entity, will 
be in memory at this time. 

4. The collection of the EntityTypes will now be 
searched again, and the appropriate pointer returned 
to the calling function. 

5. The process is complete. 
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Ma : Ge tMa th Value . 

This is illustrated in Figure 8 of the drawings. 
This function can be called by a Client system, in order 
to find out the current status of the computer system. 
Argument : None . 

1. A determination is made as to whether the decision 
source is subordinate. If it is, control passes to 
Step 2. If it is not, control passes to Step 3. 

2. The procedure sets Cube=Derived Cube. 

3. The procedure sets Cube^Normal Cube. 

4. Cube: GetValue ( ) , see below and Figure 9. The value 
is retrieved from the selected cube. 

5. Processing complete. 

Ciibe : GetValue ( ) 

This is the facility to retrieve the Decision cube's 

data which is called in Math: GetMathValue , and is 
illustrated in Figure 9. 

Arguments: Decision parameters. Decision Quantity. 

1. This process needs to translate the decision 

parameters into a node location. It therefore 
iterates through each of the decision parameters. 

2 . Selecting the Decision Dimension Key for each 
parameter in turn. 

3. It translates the key into an index into that 
dimension of the cube. (See Decision Cube) 

4. CubeKey=Vector (DimensionKeys) . The set of key 
indices thus obtained then form a vector into the 
cube, so selecting a particular node in the array. 

5. The value of the node at this cube key is then 
retrieved . 

6. Processing complete. 
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COMPUTER RESOURCES & SPECIFICATION 
While not restricted to these particular resources, 
the preferred embodiment of the system has been 
implemented on computer systems currently available. 

The prototype of the system was developed on a 
133 MHz Pentium Notebook PC with 32Mb RAM (random access 
memory) , and a 2Gb Hard Disk, running Microsoft Windows 
NT, with Microsoft Access as the Database, and with zhe 
software developed and prototyped both in Microsoft Visual 
Basic 5, and Microsoft Visual C++. 

The system was then ported to a Sun Microsys tei^s 
Ultras, running Solaris 2.51, with a Sybase System 11 SQL 
Server database resource, and written in Unix/Ansi C-+ . 

Thus, the key requirements of the system are readily 
met by the conjunction of a typical computer system, a 
typical software coding language, and a typical database 
resource . 

SOFTWARE DESIGN 
It IS readily understood that software design and 
implementation must take into account the possibility of 
function calls failing for numerous causes. Since this is 
a fundamental requirement in software engineering, which 
must be managed in any commercial implementation, the 
needs and skills appropriate to support failure will 
therefore be familiar to any software engineer skilled in 
the art. As such, they do not feature as an aspect cf the 
claims of the system, such routines and techniques for 
developing robust code have been considered immaterial to 
the explicit description of the particular embodiment of 
30 the system. 

SCOPE OF THE PREFERRED EMBODIMENT 
The preferred embodiment implements a fixed and 
limited hierarchy, of specified types yet which is of 
sufficient power to provide a modelling and management 
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facility which will cope with typical transactions and 
negotiations encompassed in the world today. 

In combination with a facility to provide agents for 
execution of processes, it then encompasses a uniform and 
general transaction facility, suitable for example 
business, domestic, military and governmental use. 

To the extent that these agents may themselves be 
computer processes, then such an environment offers a 
computerised transaction facility. Where these agents do 
not need to refer to non-computer resources for their 
information to fulfil' their transactions, then to thac 
extent, the environment so described becomes an automated 
one . 

DATABASE 

For each entity type there is a corresponding 
database table. The table is given the name of the entity 
type. Thus, the existence of a 'Thing' entity leads to 
the existence of a 'Thing* table. 

THING TABLE 

The Thing Table contains references to objects 
external to the system. Each new Thing record added to 
the table has a unique ThinglD. 



Field Name 


Type 


Notes on Usage 


ThinglD 


Long 


Uniquely identifies 
a Thing 


ClientSystem 


String 


Identifies the 
Client System 


ClientSysteiuRef erence 


Long 


Identifies the external 
object in the Client System 


CI lent Re f Description 


String 


Optional - Description 
for client convenience 
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ASSIGNMENT TABLE 

The Assignment Table contains references to processes 
to be applied to Thing entities. Each new Assignment 
record added to the table has a unique Assignment ID . 



5 



Field Name 


Type 


Notes on Usage 


Assignment ID 


Long 


Uniquely identifies an 
Assignment 


ThingRef ID 


Long 


Thing this Assignment is 
for 


Instigator 


String 


Supplied by client to 
identify who created 
entity 


InstigatorRef 


Long 


Supplied by client as 
external reference to 
Instigator 


PredecessorAssignmentRef ID 


Long 




Redirection 


String 


Precise nature of 
assignment 


Quantity 


Double 


How much of the 
redirection is requested 
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TENDER TABLE 

The tender table contains the information which 
groups proposals. Each new Tender record added to the 
table has a unique TenderlD. 



Field Name 


Type 


Notes on Usage 


TenderlD 


Long 


Uniquely identifies a Tender 


ThingRef ID 


Long 


Thing this Tender is for 


AssignmentRef ID 


Long 


The superior Assignment in the 
hierarchy 


Instigator 


String 


Supplied by client to identify 
who created entity 


InstigatorRef 


Long 


Supplied by client as external 
reference to Instigator 


Quantity 


Double 


How much this tender relates to 
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PROPOSAL TABLE 

The Proposal contains details of the negotiation wirh 
an agent to perform the process. Each new Proposal record 
added to the table has a unique ProposallD. 
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Field Name 


Type 


Notes on Usage 


ProposallD 


Long 


Uniquely identifies a 
Proposal 


ThingRef ID 


Long 


Thing this Proposal is for 


AssignmentRef ID 


Long 


The superior Assignment in 
the hierarchy 


TenderRef ID 


Long 


The superior Tender in the 
hierarchy 


Instigator 


String 


Supplied by client to 
identify who created entitv 


InstigatorRef 


Long 


Supplied by client as 
external reference to 
Instigator 


Superi j;:-.-: roposalRef ID 


Long 




SiblingP-roposalRef ID 


Long 




Dpline 


String . 


Who has an interest in the 
process being performed 


Downline 


String 


Who will perform the process 


GoingUp 


Boolean 


Who initiated the proposal 


BidWanted 


Boolean 


Does acceptance grant right 
to act 


Action 


String 


The action in regard to 
performing the process 


ConsiderQuantity 


Double 


How much of the action is 
proposed 
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DECISION TABLE 



Field Name 


Type 


Notes on Usage 


DecisionID 


Long 


Uniquely identifies a Decision 


ProposalRef ID 


Long 


Uniquely identifies a Proposal 


Instigator. 


String 


Supplied by client to identify who 
created entity 


InstigatorRef 


Long 


Supplied by client as external 
reference to Instigator 


ConsiderQuantity 


Double 




AnnulQuantity 


Double 


Amount of original proposal 
withdrawn 


DeclineQuantity 


Double 


A response. Amount declined from 
proposal 


Accept Quantity 


Double 


A response. Amount accepted from 
proposal 


ForwardQuantity 


Double 


A response. Amount forwarded from 
proposal 



INSTIGATOR AND INSTIGATOR REFERENCE 

At the creation of an entity record, the client 

system can provide two references. One is the instigator 

of the entity creation, and the other is a meaningful 

reference to the instigator. 

These fields are available for each entity type, 

however, they are of particular significance to the 

creation of Thing entities. 

DECISION SCHEMA 

The preferred embodiment implements a 
three-dimensional decision schema, with dimensions: 
Action, Authority and Resolution. 



• 



10 



15 



20 



- 28 - 

Direct fields : 

Direct fields represent the immediate description of 
the decision. The Index for each dimension in this 
embodiment is noted in brackets 
Action : 

The potential exists that 

something be done. 
[1] NotDo: The potential no longer exists 

for something to be done . 
[2] Done: The claim is that something has 

in fact been done . 



Resolution : 

[0] Consider: 

[1] Annul: 

[2] Decline : 

[3] Accept: 

[4] Forward: 



25 



Authority : 

[ 0 ] Ful lAuthori ty : 

[1] BidWanted: 



It is being put to an agent to 

(action) something . 
The (action) is no longer 
available for consideration . 
The agent declines to pursue 
the action. 

The agent accepts to pursue the 
action . 

The agent accepts the 
responsibility for the action 
but will not perform the 
action . 

Upon acceptance, the agenr is 
free to pursue the action. 
There is no authority to pursue 
the action. 



30 Notes to clarify the above: 

Consider - the preferred embodiment embeds this in the 

proposal. It is necessary for the logical process 
that it be part of the decision schema, but it more 
naturally represents the opportunity or quantity to 

35 be decided upon . 
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Annul - allows the modelling of the withdrawal of an 

offer, rather than the offer being declined by the 
invitee , 

Forward - allows the modelling of the situation where a 
salesman accepts a client order, but will not be 
fulfilling it himself. It will be fulfilled, for 
example, by the factory floor. 

BidWanted - allows a tender for a contract to be modelle* 
or an offer of tickets, where the final allocation 
will be at the discretion of the offeror, not the 
bidder . 

In the following, these are written in the order; 
Resolution . Action . Authority . 

Der-ived Fields : 

Given the events- (decisions) it is then appropriate 
to ask what the current situation is. The creation of 
derived fields therefore allows logical processing or 
mathematics to be done on the direct fields;.- The 
preferred embodiment implements the following derived 
fields. Calculations to generate the derived fields are 
noted beside the field description. The Identifiers are 
taken to indicate the values or quantities associated by 
those identifiers . 

For example: (Do - NotDo - Done = Open) should be 
read as: 



- 5 and quantity claimed as "Done" = 3, then the quantity 
remaining "Open" is 12 - 5 - 3 = 4, ie 12 minus 5 minus 3 
Dimension Indices are in brackets. 



If quantity required as "Do" = 



12, and quantity to "NotDo 



Action 



[3] Open: 



(Do - NotDo - Done) 



Everything not 



cancelled or 



complete 
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Resolution 

[5] Available: (Consider - Annul) Everything not 

withdrawn 

[6] Potential: (Available - Declined) Everything not 

^ declined 
[7] Pend.-Lng: (Potential - Accept - Forward) 

Everything not 
decided 

Authority 
10 No derived fields 



Examples 

Natural examples of decisions which may be expressed ir 
this schema therefore are : 

Accept. Do Accept to do something. 

Decline. Do: Decline to do something. 

Extending slightly: consider the following. 

Accepts Not Do Accept to Not Do something (eg: 

cancel an order) 
Decline. NotDo Declines to NotDo something (eg: too 

late to cancel . } 



Accepts that something has been 
done . 

Decline to recognise that something 
has been done , 

In the context of the system, a Do recognises the 
intent or potential to Do something, so that to Accept: . Do 
for example sets up an expectation that whatever is being 
referred to will in due course be done. 

To recognise a Do is therefore to OPEN a potential. 
To CLOSE a potential, so that it can be dismissed from 
attention, one of two things must happen. Either it will 



Consider further: 
Accept . Done : 

Decline . Done ; 

25 
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in due course be Done or a subsequent agreement will be 
set up to NotDo that which is being referred to. 

The set [Do, NotDo, Done] therefore reflects a 
fundamental and natural set of potential intents, actions 
or claims. Given a potential that something can be done, 
so the process is initiated or OPENED as a Do; and it 
remains OPEN until either there is a matching NotDo, or it 
is Done. Whereupon it is in effect CLOSED and requires no 
further attention . 

In the example outline above the decision cube will 
have dimensions [4] [8] [2] and each element of the array 
will be initialised to zero. 
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Wor-ked Example 

This will apply 2 decisions to a Cube. The first 
will reflect asking someone to consider doing 12 of_ 
something (buying .12 bottles of water, for example). The 
second will reflect the agreement of the individual to the 
proposal. The details of the nature of the transaction 
are not stored in or relevant to neither the cube nor the 
system itself. Rather, only references to the existence 
of the transaction are stored. The system manages and 
captures the complexity of the negotiation, but leaves the 
description of the transaction to the client system. 



25 



30 



Decision 1 



Decision Specification : 



Resolution : 

Action : 
Quantity : 
Authority : 



CONSIDER 

DO 
12 

FULL 



Asking someone to consider 
doing 12 of something. 
Narrative /Intuitive 
description : 

Please consider the following 

proposal 

to do 

12 (of something) 

with my permission to proceed, 

if you accept. 
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Ciibe Vector: 

(Do = 0, Consider = 0, Authority = 0): Vector = (0,0,0) 
Ciibe Node : 

The active node is therefore Cube [0] [0] [0] . 

Incrementing the value: the node's value is increased by 

the decision quantity. 

Cube[0] [0] [0] = Cube[0] [0] [0] + 12; 

The node Consider . Do . Full is now 12. 



Recalculation of the derived fields 

Only a typical case is shown here, for illustration. 
Available . Do . Full = Consider . Do . Full - Annul . Do . Ful 1 
= 12 - 0 = 12 



Decision 2: The invitee accepts 8 of the proposal 

Decision Type: Accept . Do . Full 

Decision Quantity: 8 

Decision Vector: [Do- 0] [Accept = 3] [FullAuthority = 0] 



Implementation : 

Cube[0] [3] [0] = Cube[0] [3] [0] + 8; 



Restricting to the Do. Full indices, the Resolution 
dimension therefore now looks as follows: 
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Resolution 


Quantity 


Consider 


12 


Annul 


0 


Available 


12 


Declined 


0 


Potential 


12 


Accept 


8 


Forward 


0 


Pending 


4 



For a given Action therefore, 2 key foci exist: 
How much has been Accepted; and how much is still Pending 
The first acknowledges a commitment to something, allowin 
planning. The second, unresolved but potential 
commitments, require follow-up. 

FURTHER EMBODIMENT 
The system itself is not limited to or by the 
preferred • embodiment . A more sophisticated" embodiment ma 
be implemented without impinging upon or materially 
reshaping the fundamentals of the system herein described 
Some of the additions to the preferred embodiment are now 
outlined . 

ENTITY PROPERTIES 

The system may include the entity property 
EntityCreatedAT to store its TIME of creation. 

The system may include the entity property EntityVoi 
to support a facility to remove an Entity from 
consideration, in effect deleting it without actually 
removing it from the database. 

The system may include the entity property 
EntityClosed to enable a client to decide not to post any 
further transactions to that entity. Note that this 
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restriction would not be controlled by the system but by 
the client system, otherwise it violates the 'Reflect 
don't Control' principle of the system. Additional 
properties which suggest internal control should, be 
5 avoided or renamed. 

An Assignment entity may include further information 
above and beyond the simple identification of the 
transformation. For example, if a further embodiment of 
the system were to support deadline modelling, a deadline 
10 for the Assignment might be further included as a field in 

the Assignment entity. 

AUDIT TRAIL 

The system may include an audit trail to record the 
details of all transactions passing through the system. 

15 MATH IN MEMORY 

The system may include storing the complex 
calculations in memory to speed up the overall 
performance . 



ADDITION FUNCTIONS FOR CLIENT SYSTEMS 
2° The system may include further facilities to enrich 

the range of the functionality available to the client 
system. An example is a query facility, taking advantage 
of the fact that the storage of the embodiment is a 
database, so that client applications may implement 
25 queries such as: 

Assignments outstanding: Assignments not Closed, 

Pending non-zero 
Assignments overdue: Assignments not Closed, 

Created before X Date 
Agreements in place: Proposals with Downline=Y 
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DELETING ENTITIES 
The system may include a facility to delete entity 
data. In the preferred embodiment no such facility 
exists. It is a design principle that the system does not 
'forget' or 'lose' information. The preferred embodiment 
regards data deletion, therefore, as an internal 
housekeeping function for the user. 

Clearly, on limited capacity machines, an 
unconstrained policy of adding data without any facility 
for deletion will overwhelm the resources at some point. 
Therefore, a policy on deletion of data would be prudent. 
This will typically depend on the rate of accretion of new 
data, the importance of the data, the resources available, 
and policy on data storage, archiving etc. 



CLAIMS 



1. A transactional computer system comprising a 
plurality of entities including at least one entity of 
each of the following forms: 

a first entity (Thing entity) having the properties 
of identifying a client system and uniquely identifying an 
object in that client system; 

a second entity (Proposal entity) for defining a 
transaction, the second entity being subordinate directly 
or indirectly to a first entity and having the properties 
of modelling at least one external agent to carry out a 
transformation in relation to the first entity; and 

a third entity (Decision entity) capable of 
communicating with a second entity and having the 
properties of defining the types of decision that may be 
made, and determining the responses in relation to those 
decisions . 

2. A computer system according to claim 1, further 
comprising at least one fourth entity (Assignment entity) 
subordinate to an associated first entity, the fourth 
entity having the properties of uniquely identifying the 
associated first 'entity, and identifying a particular type 
of assignment or transformation to be applied to the first 
entity . 

3. A computer system according to claim 2, in which the 
fourth entity also identifies a quantity. 

4 . A transactional computer system comprising a 
plurality of entities including at least one entity of 
each of the following forms: 

a first entity (Thing entity) having the properties 
of identifying a client system and uniquely identifying an 
object in that client system; 
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a second entity (combined Proposal /Assignment entity) 
for defining a transaction, the second entity being 
subordinate to a first entity and having the properties of 
(i) modelling at least one external agent to carry out a 
transformation in relation to the first entity, and (ii) 
uniquely identifying the associated first entity, and 
identifying a particular type of assignment or 
transformation to be applied to the first entity; and 

a third entity (Decision entity) capable of 
communicating with a second entity and having the 
properties of defining the types of decision that may be 
made, and determining the responses in relation to those 
decisions . 

5. A computer system according to claim 4, in which the 
second entity also identifies a quantity. 

6. A computer system according to any preceding claim, 
in which an agent modelled by the second entity includes 
at least cwo parties to a transaction. 

7. A computer system according to claim 6, in which the 
second entity additionally identifies the direction of 
negotiation between the parties . 

8. A computer system according to any preceding claim, 
further comprising at least one second entity (Subordinate 
Proposal entity) which is subordinate to another second 
entity, and includes the property of identifying the other 
second entity to which it is subordinate. 

9. A computer system according to any preceding claim, 
further comprising a plurality of associated second 
entities (Sibling Proposal entities) all of which are 
directly subordinate to another second entity and each 
including the property of identifying the other second 
entity to which they are subordinate whereby the said 
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associated second entities include quantities which 
together correspond to the quantity of the said another 
second entity to which they are subordinate . 



10. A computer system according to any preceding claim, 
in which the third entity is multidimensional and contains 
multidimensional vectors indicative of values resulting 
from an associated second entity . 



11. A computer system according to claim 10, in which at 
least one third entity is a partial entity indicating a 
partial response from a second entity. 



12. A computer system according to any preceding claim, 
further comprising at least one further entity (Tender 
entity) associated with a plurality of second entities and 
a single first entity, and identifying at least a 
quantity . 

13. A computer system according to any preceding claim, 
in which the system does not validate data input into the 
system . 

14. A computer system according to any preceding claim, 
in which the system provides for at least the following 
functions : 

(i) creation of a new entity, 

(ii) loading a selected entity or entities into a working 
memory of the computer system, 

(iii) incrementing a multidimensional array, 

(iv) retrieving a value from an entity, and 

(v) advising the client system of an event. 

15. A transactional computer system substantially as 
herein described with reference to the drawings. 
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